Unpack instruction

ABSTRACT

A processor executes an instruction that causes a source data field from a programmable position within a first source register to be copied to a destination register. The instruction is particularly useful for generating media-based bitstreams (e.g., audio, video). In some embodiments, a system (e.g., a communication device such as cellular telephone) includes a processor capable of executing the instruction as described above.

CROSS REFERENCE TO RELATED CASES

This application claims the benefit of European Patent Application No.04291918.3, filed Jul. 27, 2004, incorporated by reference herein as ifreproduced in full below.

BACKGROUND

1. Technical Field

The present subject matter relates generally to processors and moreparticularly to an executable instruction that copies at least a portionof the contents of a register to a destination register at aprogrammable location within the destination register.

2. Background Information

Many types of electronic devices are battery operated and thuspreferably consume as little power as possible. An example is a cellulartelephone. Further, it may be desirable to implement various types ofmultimedia functionality in an electronic device such as a cell phone.Examples of multimedia functionality may include, without limitation,games, audio decoders, digital cameras, etc. It is thus desirable toimplement such functionality in an electronic device in a way that, allelse being equal, is fast, consumes as little power as possible andrequires as little memory as possible. Improvements in this area aredesirable.

BRIEF SUMMARY

In at least one embodiment, a processor executes an instruction thatcauses a source data field from a programmable position within a firstsource register to be copied to a destination register. In someembodiments, a system (e.g., a communication device such as cellulartelephone) includes a processor capable of executing the instruction asdescribed above.

In another embodiment, a method of executing an instruction is disclosedthat comprises examining the instruction to determine a first sourceregister and determining a programmable position within the first sourceregister. The method further comprises copying a source data field fromthe programmable position within the first source register to adestination register.

In general, the instruction is useful to extract a subset of bits from aregister. The subset might represent, for example, a variable. Forexample, a 32 bit register might contain 9 variables of 3 bits each andone 5-bit variable. The instruction described herein permits theefficient retrieval of each separate variable from the source register.The instruction can be used in some embodiments for processingmedia-based bitstreams (e.g., audio, video).

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claimsto refer to particular system components. As one skilled in the art willappreciate, various companies may refer to a component by differentnames. This document does not intend to distinguish between componentsthat differ in name but not function. In the following discussion and inthe claims, the terms “including” and “comprising” are used in anopen-ended fashion, and thus should be interpreted to mean “including,but not limited to.” Also, the term “couple” or “couples” is intended tomean either an indirect or direct connection. Thus, if a first devicecouples to a second device, that connection may be through a directconnection, or through an indirect connection via other devices andconnections.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed description of the preferred embodiments of thepresent invention, reference will now be made to the accompanyingdrawings, wherein:

FIG. 1 shows a diagram of a system in accordance with preferredembodiments of the invention and including a Java Stack Machine (“JSM”)and a Main Processor Unit (“MPU”);

FIG. 2 illustrates an embodiment of the invention in the form of awireless communication device such as a cellular telephone;

FIG. 3 shows a block diagram of the JSM of FIG. 1 in accordance withpreferred embodiments of the invention;

FIG. 4 shows various registers used in the JSM;

FIG. 5 shows a function performed by an UNPACK instruction in accordancewith the preferred embodiment of the invention; and

FIGS. 6 and 7 show exemplary formats of the UNPACK instruction inaccordance with a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following discussion is directed to various embodiments of theinvention. Although one or more of these embodiments may be preferred,the embodiments disclosed should not be interpreted, or otherwise used,as limiting the scope of the disclosure, including the claims, unlessotherwise specified. In addition, one skilled in the art will understandthat the following description has broad application, and the discussionof any embodiment is meant only to be exemplary of that embodiment, andnot intended to intimate that the scope of the disclosure, including theclaims, is limited to that embodiment.

The subject matter disclosed herein is directed to a programmableelectronic device such as a processor that executes various instructionsincluding, without limitation, an “UNPACK” instruction. As will beexplained in detail below, the UNPACK instruction permits the extraction(“unpacking”) of a portion of the data from a bit stream by copying someof the contents of a source register beginning at a designated locationto a predetermined location within a destination register (e.g., thelowest significant bits of the destination register). The UNPACKinstruction is particularly useful for extracting portions of, forexample, media-based bitstreams (e.g., audio, video). The followingdescribes the operation of a preferred embodiment of a processor onwhich the UNPACK instruction may run. Other processor architectures andembodiments may be available or developed on which to run theinstruction and thus this disclosure and the claims which follow are notlimited to any particular type of processor. Details regarding theoperation and format of the UNPACK instruction follow the description ofthe processor.

The processor described herein is particularly suited for executingJava™ Bytecodes or comparable code. As is well known, Java isparticularly suited for embedded applications. Java is a relatively“dense” language meaning that on average each instruction may perform alarge number of functions compared to various other programminglanguages. The dense nature of Java is of particular benefit forportable, battery-operated devices that preferably include as littlememory as possible to save space and power. The reason, however, forexecuting Java code is not material to this disclosure or the claimswhich follow. The processor described herein may be used in a widevariety of electronic systems. By way of example and without limitation,the Java-executing processor described herein may be used in a portable,battery-operated communication device such as a cellular telephone,personal data assistants (“PDAs”), etc. Further, the processoradvantageously includes one or more features that permit the executionof the Java code to be accelerated.

Referring now to FIG. 1, a system 100 is shown in accordance with apreferred embodiment of the invention. As shown, the system includes atleast two processors 102 and 104. Processor 102 is referred to forpurposes of this disclosure as a Java Stack Machine (“JSM”) andprocessor 104 may be referred to as a Main Processor Unit (“MPU”).System 100 may also include memory 106 coupled to both the JSM 102 andMPU 104 and thus accessible by both processors. At least a portion ofthe memory 106 may be shared by both processors meaning that bothprocessors may access the same shared memory locations. Further, ifdesired, a portion of the memory 106 may be designated as private to oneprocessor or the other. System 100 also includes a Java Virtual Machine(“JVM”) 108, compiler 110, and a display 114. The JSM 102 and/or MPU 104preferably includes an interface to one or more input/output (“I/O”)devices such as a keypad to permit a user to control various aspects ofthe system 100. In addition, data streams may be received from the I/Ospace into the JSM 102 to be processed by the JSM 102. Other components(not specifically shown) may include, without limitation, a battery andan analog transceiver to permit wireless communications with otherdevices. As noted above, while system 100 may be representative of, oradapted to, a wide variety of electronic systems, an exemplaryelectronic system may comprise a battery-operated, mobile cell phonesuch as that is shown in FIG. 2.

As shown in FIG. 2, a mobile communications device includes anintegrated keypad 412 and display 414. Two processors and othercomponents may be included in electronics package 410 connected tokeypad 412, display 414, and radio frequency (“RF”) circuitry 416 whichmay be connected to an antenna 418.

As is generally well known, Java code comprises a plurality of“bytecodes” 112. Bytecodes 112 may be provided to the JVM 108, compiledby compiler 110 and provided to the JSM 102 and/or MPU 104 for executiontherein. In accordance with a preferred embodiment of the invention, theJSM 102 may execute at least some, and generally most, of the Javabytecodes. When appropriate, however, the JSM 102 may request the MPU104 to execute one or more Java bytecodes not executed or executable bythe JSM 102. In addition to executing Java bytecodes, the MPU 104 alsomay execute non-Java instructions. The MPU 104 also hosts an operatingsystem (“O/S”) (not specifically shown), which performs variousfunctions including system memory management, system task management forscheduling the JVM 108 and most, or all, other native tasks running onthe system, management of the display 114, receiving input from inputdevices, etc. Without limitation, Java code may be used to perform anyone of a variety of applications including multimedia data processing,games or web-based applications, while non-Java code, which may comprisethe O/S and other native applications, may still run on the system onthe MPU 104.

The JVM 108 generally comprises a combination of software and hardware.The software may include the compiler 110 and the hardware may includethe JSM 102. The JVM may include a class loader, bytecode verifier,garbage collector, and a bytecode interpreter loop to interpret thebytecodes that are not executed on the JSM processor 102.

In accordance with preferred embodiments of the invention, the JSM 102may execute at least two instruction sets. One instruction set maycomprise standard Java bytecodes. As is well-known, Java is astack-based programming language in which instructions generally targeta stack. For example, an integer add (“IADD”) Java instruction pops twointegers off the top of the stack, adds them together, and pushes thesum back on the stack. The JSM 102 comprises a stack-based architecturewith various features that accelerate the execution of stack-based Javacode, such as those described in U.S. patent Pub. Nos. 2004/0078550,2004/0078557, and 2004/0024999, all of which are incorporated herein byreference.

Another instruction set executed by the JSM 102 may include instructionsother than standard Java instructions. In accordance with at least someembodiments of the invention, such other instruction set may includeregister-based and memory-based operations. This other instruction setgenerally complements the Java instruction set and, accordingly, may bereferred to as a complementary instruction set architecture (“CISA”). Bycomplementary, it is meant that the execution of one or more Javabytecodes may be substituted by “microsequences” using CISA instructionsthat enable faster, more efficient operation. In addition to CISAinstructions, a micro-sequence may also include Java bytecodes. The twosets of instructions may be used in a complementary fashion to obtainsatisfactory code density and efficiency. As such, the JSM 102 generallycomprises a stack-based architecture for efficient and acceleratedexecution of Java bytecodes combined with a register-based architecturefor executing register and memory based CISA instructions. Botharchitectures preferably are tightly combined and integrated through theCISA.

FIG. 3 shows an exemplary block diagram of the JSM 102. As shown, theJSM includes a core 120 coupled to data storage 122 and instructionstorage 130. The core may include one or more components as shown. Suchcomponents preferably include a plurality of registers 140, addressgeneration units (“AGUs”) 142, 147, micro-translation lookaside buffers(micro-TLBs) 144, 156, a multi-entry micro-stack 146, an arithmeticlogic unit (“ALU”) 148, a multiplier 150, decode logic 152, andinstruction fetch logic 154. In general, operands may be retrieved fromdata storage 122 or from the micro-stack 146 and processed by the ALU148, while instructions may be fetched from instruction storage 130 byfetch logic 154 and decoded by decode logic 152. The address generationunit 142 may be used to calculate addresses based, at least in part, ondata contained in the registers 140. The AGUs 142 may calculateaddresses for CISA instructions. The AGUs 142 may support parallel dataaccesses for CISA instructions that perform array or other types ofprocessing. AGU 147 couples to the micro-stack 146 and manages overflowand underflow conditions in the micro-stack, preferably in parallel. Themicro-TLBs 144, 156 generally perform the function of a cache for theaddress translation and memory protection information bits that arepreferably under the control of the operating system running on the MPU104.

Referring now to FIG. 4, the registers 140 may include 16 registersdesignated as R0-R15. All registers are 32-bit registers in accordancewith the preferred embodiment of the invention. Registers R0-R5 andR8-R14 may be used as general purpose (“GP”) registers, thereby usablefor any purpose by the programmer. Other registers, and at least one ofthe GP purpose registers, may be used for specific functions. Forexample, in addition to use as a GP register, register R5 may be used tostore the base address of a portion of memory in which Java localvariables may be stored when used by the current Java method. The top ofthe micro-stack 146 is reflected in registers R6 and R7. The top of themicro-stack has a matching address in external memory pointed to byregister R6. The values contained in the micro-stack are the latestupdated values, while their corresponding values in external memory mayor may not be up to date. Register R7 provides the data value stored atthe top of the micro-stack. Register R15 is used for status and controlof the JSM 102.

Referring again to FIG. 3, as noted above, the JSM 102 is adapted toprocess and execute instructions from at least two instruction sets. Oneinstruction set includes stack-based operations and the secondinstruction set includes register-based and memory-based operations. Thestack-based instruction set may include Java bytecodes. Java bytecodespop, unless empty, data from and push data onto the micro-stack 146. Themicro-stack 146 preferably comprises the top n entries of a larger stackthat is implemented in data storage 122. Although the value of n mayvary in different embodiments, in accordance with at least someembodiments, the size n of the micro-stack may be the top eight entriesin the larger, memory-based stack. The micro-stack 146 preferablycomprises a plurality of gates in the core 120 of the JSM 102. Byimplementing the micro-stack 146 in gates (e.g., registers) in the core120 of the processor 102, access to the data contained in themicro-stack 146 is generally very fast, although any particular accessspeed is not a limitation on this disclosure.

The second, register-based, memory-based instruction set may comprisethe CISA instruction set introduced above. The CISA instruction setpreferably is complementary to the Java bytecode instruction set in thatthe CISA instructions may be used to accelerate or otherwise enhance theexecution of Java bytecodes. For example, the compiler 110 may scan aseries of Java bytes codes 112 and replace one or more of such bytecodeswith an optimized code segment mixing CISA and bytecodes and which iscapable of more efficiently performing the function(s) performed by theinitial group of Java bytecodes. In at least this way, Java executionmay be accelerated by the JSM 102. The CISA instruction set includes aplurality of instructions including an “UNPACK” instruction as mentionedabove and explained below in detail.

Referring still to FIG. 3, the ALU 148 adds, subtracts, and shifts data.The multiplier 150 may be used to multiply two values together in one ormore cycles. The instruction fetch logic 154 generally fetchesinstructions from instruction storage 130. The instructions are decodedby decode logic 152. Because the JSM 102 is adapted to processinstructions from at least two instruction sets, the decode logic 152generally comprises at least two modes of operation, one mode for eachinstruction set. As such, the decode logic unit 152 may include a Javamode in which Java instructions may be decoded and a CISA mode in whichCISA instructions may be decoded.

The data storage 122 generally comprises data cache (“D-cache”) 124 anddata random access memory (“D-RAMset”) 126. Reference may be made toU.S. pat. Publications Ser. No. 09/591,537 filed Jun. 9, 2000 (attydocket TI-29884), Ser. No. 09/591,656 filed Jun. 9, 2000 (atty docketTI-29960), Ser. No. 09/932,794 filed Aug. 17, 2001 (atty docketTI-31351), and U.S. patent Pub. No. 20040260904, all of which areincorporated herein by reference, for information related to theD-RAMset. The stack (excluding the micro-stack 146), arrays andnon-critical data may be stored in the D-cache 124, while Java localvariables, critical data and non-Java variables (e.g., C, C++) may bestored in D-RAMset 126. The instruction storage 130 may compriseinstruction RAM (“I-RAM”) 132 and instruction cache (“I-cache”) 134.

One of the CISA instructions, as noted above, is the “UNPACK”instruction. The function performed by the UNPACK instruction isillustrated in FIG. 5. As shown, the function performed by the UNPACKinstruction is to copy the contents of a source data field 200 from asource register (Rs1) to a destination register (Rd). The location ofthe source data field 200 is identified by a position value P whichitself may be provided by a second source register (Rs2). The identityof registers Rs1 and Rd, the size m of source data field 200, and theposition value P preferably are all programmable.

The size of the source data field 200 in source register Rs1 is m bitsand the value of m is included as a field within the UNPACK instructionitself. The position value P identifies, in some embodiments, the leastsignificant bit of Rs1 at which the source data field 200 begins. Forexample, the source data field 200 may begin at bit number 5 of Rs1 andextend to bit number 10. The position value P may correspond to bitnumber 5. In other embodiments, the position value P points to the bitwithin register Rs1 that corresponds to the most significant bit of thesource data field 200. In the prior example, the position value P maycorrespond to bit number 10. The various fields in the UNPACKinstruction will be explained below with regard to FIGS. 6 and 7.

Multiple embodiments of a UNPACK instruction are possible. Two suchembodiments are depicted in FIGS. 6 and 7. The state of bit 15differentiates the two versions of the UNPACK instruction in FIGS. 6 and7. A “0” in bit 15 designates the UNPACK instruction embodiment of FIG.6, while a “1” designates the UNPACK instruction embodiment of FIG. 7.

As shown in FIG. 6, the UNPACK instruction is a 32-bit instruction,although the number of bits for the instruction can be varied asdesired. In the embodiment of FIG. 6, the UNPACK instruction comprisesfields 250-266. Field 250 comprises an instruction class value thatidentifies the class to which the instruction pertains. Some classes mayhave only a single instruction pertaining thereto and thus theinstruction class field 250 identifies the particular instruction(similar to an opcode). The UNPACK instruction pertains to aninstruction class that includes multiple instructions including UNPACKand other instructions. In this situation, the particular instruction isidentified by the OpX1 value in field 266. Thus, the OpX1 value in FIG.6 is a value that uniquely identifies the instruction as an UNPACKinstruction. Moreover, the instruction class fields 250 and OpX1 fields266 are the same between FIGS. 6 and 7, and the differentiation betweenthe two versions of UNPACK results from the status of field 258 (bit 15)as explained above.

Bits 24 through 27 (field 252) comprise a 4-bit field that identifiesthe particular register to be used as the destination register Rd. Asshown in FIG. 4, multiple registers can function as general purposeregisters and thus can function as the destination register Rd. Thesource register Rs1, from which the source data field 200 originates, isdesignated by bits 20 through 23 (field 254) in the instruction and canbe one of the GP registers in FIG. 4.

Bits 16 through 19 (field 256) specify the other source register Rs2which contains the position value P which identifies the location withinsource register Rs1 of the source data field 200. As for the sourceregister Rs1, source register Rs2 containing the position value P ispreferably one of the general purpose registers depicted in FIG. 4.

The state of bit 14 (field 260, shown as the “E” field) designateswhether sign extension is to be employed when copying the source datafield 200 into the destination register Rd. Referring briefly to FIG. 5,the most significant bit of the source data field 200 in register Rd isidentified by reference numeral 202. Field 204 in register Rd representsall of the bits within Rd outside the bits that are written to with thesource data field 200. The question becomes what state (0 or 1) to makethe bits in field 204. In one embodiment, all of the bits in field 204are forced to a predetermined state (e.g., 0). In other embodiment, thestate of the most significant bit 202 of the source data field 200 issign-extended to all of the bits in field 204. For example, if bit 202is a 0, then all bits in field 204 become 0. Alternatively, if bit 202is a 1, then all bits in field 204 become 1. Essentially, the state ofbit 202 is propagated through each of the bits field 204. Bit 14 in theUNPACK instruction dictates how the bits in field 204 are to be set. Forexample, a value of 1 for the sign extension field 260 designates thatsign extension is to be employed when copying source data field todestination register Rd, while a value of 0 for the sign extension field260 designates that all bits in field 204 are to be set to apredetermined value (e.g., 0).

Bits 9 through 13 (field 262) not used in the particular embodiment ofUNPACK depicted in FIG. 6. As such, bits 9 to 13 are set at a value of0. The UNPACK instruction embodiment of FIG. 7 does use bits 9 through13 as will be explained below. The value of m, which defines the widthof the source data field 200 (i.e., the number of bits of field 200), isprovided in bits 4 through 8 (field 264) of the UNPACK instruction. As a5-bit value, m can specify a width from 1 bit to 32 bits. As theregisters are 32-bit registers in the embodiments described herein, an mvalue of 32 means that the entire contents of source register Rs1 is tobe copied to destination register Rd. Of course, it is incumbent on theprogrammer to ensure that the position value P and the source data fieldwidth value m are consistent with each other. That is, a P value of 30(designating bit 30 in register Rs1) is inconsistent with an m value of15 in that are not 15 bits in the 32-bit register Rs1 starting at bit30.

In FIG. 5 the position value P comes from the second source register Rs2which is identified by field 256 in the UNPACK instruction format ofFIG. 6. FIG. 7 shows another format for the UNPACK instruction. Theformat of FIG. 7 is similar to that of FIG. 6 in that the same fieldsare provided for the instruction class and OpX1 values, the identity ofthe destination register Rd, the identity of the source register Rs1containing the source data field 200, the E field designating whether toemploy sign extension, and the value of m defining the size of thesource data field 200. Field 256 (bits 16 through 19), however, nolonger identify a second source register Rs2 for the P value. Insteadfield 262 (bits 9 through 13) include the position value P itself ratherthan a pointer to a register that contains the P value.

In the embodiments described above, the value of m is contained in theinstruction itself. In other embodiments, the instruction may contain anidentifier of a register that contains the value of m. For example,rather than bits 4 through 8 containing the value of m, those bits couldidentify the register from among the register set (FIG. 4) that containsthe value of m. Separate OpX1 values can be used to encode differentversions of the UNPACK instruction—one in which the m value is in field264 and another in which field 264 contains an identifier of a registerthat contains the m value.

In still another embodiment of the UNPACK instruction, the value of P iscontained in the instruction itself (similar to the embodiment of FIG.7) and bit 15 is used to specify whether the instruction contains thevalue of m or rather the instruction contains an identifier of aregister that contains the value of m (as explained above). In otherwords bit 15 could be used in a similar fashion as described above todifferentiate the two versions of the UNPACK instruction, but ratherthan differentiating where to find the value of P while in both versionsthe instruction always contains the value of m, the two versions coulddifferentiate where to find the value of m while the instruction alwayscontains the value of P. Moreover, in various embodiments, m and P areprogrammable as to their source location.

As noted above, the UNPACK instruction permits a portion from adesignated location of a designated source register to be copied to adesignated destination register. The UNPACK instruction providesflexibility to specify the source register that contains the data fieldto be copied, the size of the data field to be copied, the positionwithin the source register of the data field to be copied, and thedestination register into which the data field is to be copied.

The UNPACK instruction described herein permits a bit stream to be“unpacked” in an efficient, quick manner. The UNPACK instruction can beexecuted multiple times to copy multiple source data fields to adestination register to unpack various portions of a source bit streamcontained in a particular register.

While the preferred embodiments of the present invention have been shownand described, modifications thereof can be made by one skilled in theart without departing from the spirit and teachings of the invention.The embodiments described herein are exemplary only, and are notintended to be limiting. Many variations and modifications of theinvention disclosed herein are possible and are within the scope of theinvention. Accordingly, the scope of protection is not limited by thedescription set out above. Each and every claim is incorporated into thespecification as an embodiment of the present invention.

1. A processor executing a plurality of instructions, comprising: anarithmetic logic unit (ALU); and a plurality of registers coupled to theALU; wherein said processor executes an instruction that causes a sourcedata field from a programmable position within a first source registerto be copied to a destination register.
 2. The processor of claim 1wherein the position is programmable by a position value provided withinthe instruction.
 3. The processor of claim 1 wherein the position isprogrammable by a position value contained in a second source register.4. The processor of claim 3 wherein the instruction includes a pointerto the second source register.
 5. The processor of claim 1 wherein theinstruction includes a pointer to the first source register.
 6. Theprocessor of claim 1 wherein the instruction includes a pointer to thedestination register.
 7. The processor of claim 1 wherein theinstruction comprises a size value that specifies a size of the sourcedata field in the first source register.
 8. The processor of claim 1wherein the instruction comprises an identifier of a register containinga size value that specifies a size of the source data field in the firstsource register.
 9. The processor of claim 1 wherein the position isother than a least significant bit of the source register.
 10. Theprocessor of claim 1 wherein the instruction causes a most significantbit of the source data field to be copied to at least one other bitoutside the source data field in the destination register.
 11. Theprocessor of claim 1 wherein the instruction causes all bits outside thesource data field in the destination register to be set to apredetermined logic state.
 12. The processor of claim 1 wherein theinstruction comprises a programmable sign extension field whichspecifies whether a most significant bit of the source data field in thedestination register is to be sign extended to more significant bits.13. A method of executing an instruction, comprising: examining theinstruction to determine a first source register; determining aprogrammable position within the first source register; and copying asource data field from the programmable position within the first sourceregister to a destination register.
 14. The method of claim 13 whereindetermining the position comprises obtaining a position value containedin the instruction.
 15. The method of claim 13 wherein determining theposition comprises obtaining a position value contained in a secondsource register identified in the instruction.
 16. The method of claim13 further comprising examining the instruction to determine a size ofthe source data field to copy in the first source register to copy tothe destination register.
 17. The method of claim 13 wherein theprogrammable position corresponds to a bit other than a leastsignificant bit of the first source register.
 18. The method of claim 13further comprising propagating a state of a most significant bit of thesource data field to more significant bits within the destinationregister.
 19. A system, comprising: a main processor unit; and aco-processor coupled to said main processor unit, wherein saidco-processor executes an instruction that causes a source data fieldlocated at a programmable position within a first source register to becopied to a destination register.
 20. The system of claim 19 wherein theposition is programmable by a position value provided within theinstruction.
 21. The system of claim 19 wherein the position isprogrammable by a position value contained in a second source registerthat is identified in the instruction.
 22. The system of claim 19wherein the instruction includes a pointer to the first source register.23. The system of claim 19 wherein the instruction includes a pointer tothe destination register.
 24. The system of claim 19 wherein theinstruction comprises a size value that specifies a size of the sourcedata field in the first source register.
 25. The system of claim 19wherein the instruction comprises a programmable sign extension fieldwhich specifies whether a most significant bit of the source data fieldis to be sign extended to more significant bits of the destinationregister.
 26. The system of claim 19 wherein the system comprises acommunication device.